1. Field of the Invention
This invention relates to configuring and distributing software in network environments including Web-centric and Internet-centric environments, and in particular to configuring pluggable components prior to distribution to embedded servers in a network environment.
2. Description of the Related Art
The Internet is growing at an unprecedented rate, and attracting new kinds of users. In the early 1990s, only universities, the government, and some technical professionals had Web access; now consumers, small businesses, and small devices are on the Internet. As more and more people and devices come on-line, opportunities for new applications open up.
While the Internet has grown rapidly into a primary vehicle for quick information, an unexpected side benefit has also emerged—the Internet is the ideal mechanism for enabling, programming, updating, and extending “smart” appliances and devices. For previously “dumb” devices like washers, air-conditioners, and sprinklers, powerful new capabilities are becoming possible using a combination of Internet access, “embedded” microchips, and “smart” software.
Embedded applications run on microcomputers that are embedded within electronic devices such as appliances, vending machines, gasoline pumps, cellular phones, or pagers. Embedded systems are also being used to develop a new line of sophisticated devices such as personal data assistants (PDAs), smart pagers, and Web phones. The latest Web phones now support a variety of useful services, such as an address book, an auto-dialer, an Internet browser, and a calendar. These embedded computers are constrained in terms of space, power, memory, and network connectivity. But in accordance with Moore's law, these constraints have relaxed, and embedded systems have become much more powerful.
Although memory is not quite as scarce as it once was, embedded systems still have limited local memory resources. Only so much space is available for pre-installed services. But if services can be loaded on demand, then a small microprocessor can become a much more versatile computing system. Where once a device could perform only one or two operations, now it can perform a wide variety of operations. This approach to embedded services simplifies management of the devices. The services can be maintained and administered in a centralized location, and can be delivered via the network as required. Users are no longer required to replace the entire device in order to upgrade to new services or capabilities. They simply load a new version of the controlling service.
Embedded server technology has been developed to provide a framework for supporting embedded services. Sun Microsystems' Java Embedded Server™ (JES) is an example of an embedded server framework. FIG. 1 illustrates an example Embedded Server 100 with several network-deliverable services 102 installed including an HTTP protocol service, a logging service, a management service, an SNMP protocol service, and a calendar service.
Embodiments of an embedded server framework may include several components. An embedded server may provide a runtime framework that manages the loading, installation, activation, execution, and removal of one or more services and/or pluggable components. A service may be a specific set of functionality that implements an interface provided by the embedded server. For example, a service could be an application, a specific implementation of a protocol like HTTP or Remote Method Invocation (RMI), or some other set of code intended for a specific purpose, like a logging service. A service may be defined by what it does. A service description may be defined as the name under which a service is registered with the embedded server. Service descriptions allow the embedded server framework to host multiple instances and/or implementations of the same interface. A wizard may be code used by the embedded server framework to correctly manage the life cycle of a service. Life-cycle management may include installing, configuring, activating, updating, deactivating, and uninstalling a service.
In one embodiment, a pluggable component, which may also be referred to as a bundle, may be a container (e.g. Java ARchive (JAR) file) that may include the full set of classes and methods (e.g. Java classes and methods) and/or other resources (e.g. files, data, configuration information including preferences, etc.) needed to implement a service or services (and the set of wizards needed to manage the service) on an embedded server. A pluggable component may include one or more services and sets of wizards. A pluggable component may be narrowly defined and only contain a limited number of files and functionality, or it may be broadly defined to contain much more. The code contained in a pluggable component, when executed, may be thought of as a program or application. The program executes in a component context or bundle context. Each pluggable component in the embedded server may have its own unique component context. This makes it possible for several instances of the same pluggable component to run concurrently within the embedded server, each with its own component context and set of wizards. A manifest may be defined as a file within a pluggable component in which information regarding the pluggable component, for example, configuration information and dependencies on other pluggable components or resources, may be stated.
Services may be installed into an embedded server as part of a pluggable component. However, there is not necessarily a one-to-one correlation between a pluggable component and a service. The code that makes up two or more services can be packaged into one pluggable component and installed into the embedded server.
An embedded server may reside on a device, such as an embedded system, on which installed services are executed, or may reside on a gateway device that serves one or more devices. FIG. 2 illustrates a residential system with a number of devices connected to a gateway device that hosts an embedded server. In this embodiment, the embedded server on the gateway device may receive pluggable components from the network and provide the pluggable components and/or services provided by the pluggable components to one or more of the attached devices. The gateway device may store the pluggable components or may delete the pluggable components when no longer needed. A gateway device may be a standalone device. Alternatively, a device such as a VCR or home computer may serve as a gateway device. The same model as shown in the residential system example of FIG. 2 may be applied to other systems, such as enterprise systems comprising computing devices, printers, PDAs, routers, modems, etc.
Currently, in order to support multiple clients with varied configurations, pluggable components are typically manually configured after deployment, or configured individually (one at a time). In addition, some pluggable components may not be configurable after deployment. Therefore, it is desirable to provide a method for configuring network deliverable pluggable components prior to the components being deployed.